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REMARKS 

Claims 1-23 are pending in the application. 

Claims 1-23 are rejected under 35 U.S.C. 102(b) as being anticipated by Stone 
et al., UNIX Fault Management: A Guide for System Administration, Chapters 3-6 and 9, 
hereinafter "Stone". Applicant respectfully traverses this rejection. 

Claim 1 provides a method carried out by a status engine for monitoring services 
of an information technology (IT) environment. The method is based on a service 
model including service model elements that each represent a service of the IT 
environment and are each associated with a service model status. The service model 
elements include at least one superordinate service model element and at least one 
subordinate service model element. 

The mettiod includes calculating a status of the at least one superordinate 
service model element by considering status dependency and propagation between the 
service model elements within the service model The status of the at least one 
superordinate service model element depends on a status of the at least one 
subordinate service model element. 

The method calculates the status of the at least one superordinate service model 
element according to one or more rules. The rules define the dependency of the status 
of the at least one superordinate service model element on the status of the at least one 
subordinate service model element and a propagation of the status from the at least one 
subordinate service model element to the at least one superordinate service model 
element 

The rules include at least one of a) a rule that is based on additional attributes of 
at least one of the service model elements other than the service model status, b) a rule 
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that ignores the at least one subordinate service model element, c) a rule that is defined 
by a user on the basis of at least one of i) logical and ii) arithmetical operations of the 
status or the attributes of the at least one subordinate service model element, and d) a 
rule that is programmed individually by a user. 

Stone discloses tools and methods for fault management, which includes the 
process of detecting, reporting and reacting to faults or events taking place in a 
computing environment (Chapter 2, page 4, lines 13-14). An example of an event is the 
failure of a particular IT service. Stone discloses the generation of messages in 
response to events occurring at the IT services. The generated messages transport the 
status of the event to a management station where they can be viewed by a user. The 
status of an IT service is assessed solely on the basis of messages reporting the 
severity of the event occurring at the corresponding IT service. 

The Office Action, in response to Applicants previous reply, contends that the 
MC/ServiceGuard simultaneously monitors the status of all network components and 
includes monitoring rules to consider the status of each network component and the 
interdependences of each network component with all of the other network components 
(Office Action, page 15). MC/ServiceGuard is a software product that detects system 
failures, network or LAN card failures, and the failure of critical applications (Chapter 4, 
p. 59), When a system failure is detected by MC/ServrceGuard, rt moves all critical 
resources to an alternate node (Chapter 4, p. 61) 

MC/ServiceGuard simply provides a tool for monitoring events. Although 
dependencies may exist between superordinate and subordinate elements, Stone does 
not appear to disclose that MC/ServiceGuard has any capability of factoring these 
dependencies into received event messages. 

In contrast, claim 1 provides a method for calculating the status of a 
superordinate service model element. Unlike MC/ServiceGuard, or other systems 
disclosed in Stone, the method of claim 1 Is not solely dependent on a message 
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triggered by an event, which can fail to include information about subordinate elements 
that contributed to a failure. Rather, the method of claim 1 includes calculating status 
based on a status of one or more subordinate elements. 

The Office Action also contends that the use of MC/ServiceGuard with EMS 
enables a user to make explicit links between an application and its dependent 
resources, and thus rules for determining the dependent status of the application will 
consider the status of the underlying components. Again, Applicants respectfully 
disagree. Although a status of a superordinate component may depend on the status of 
a subordinate component, this fact in itself does not impry that any method providing 
status information disclosed in Stone explicitly utilizes status information of subordinate 
components in the status calculation of the superordinate component. 

Thus, Stone does not disclose a method for calculating the status of at least one 
superordinate service model element "by considering status dependency and 
propagation between the service model elements within the service model,*' nor does 
Stone disclose a method "wherein the status of the at least one superordinate service 
model element depends on a status of the at least one subordinate service model 
element". Furthermore, Stone does not disclose rules that "define the dependency of 
the status of the at least one superordinate service model element on the status of the 
at least one subordinate service model element and a propagation of the status from the 
at least one subordinate service model element to the at least one superordinate 
service model element." 

Therefore, Stone fails to disclose or suggest the elements of claim 1. Therefore, 
claim 1 patentable over Stone, 

Claims 2-8 and 21 depend from claim 1 . For at least reasoning similar to that 
provided in support of the patentability of claim 1 , claims 2-8 and 21 are also patentable 
over Stone. 
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Independent claims 9 and 16 recite features similar to those recited in claim 1. 
For at least reasoning similar to that provided in support of the patentability of claim 1, 
claims 9 and 16 are patentable over Stone. 

Claims 10-15 and 22 depend from claim 9. Claims 17-20 and 23 depend from 
claim 16. For at least reasoning similar to that provided in support of the patentability of 
claims 9 and 16, claims 10-15, 17-20, 22 and 23 are patentable over Stone. 

For the reasons set forth above, the rejection of claims 1-23 under 35 U.S.C. 
102(b) as anticipated by Stone is overcome. Applicant respectfully requests that the 
rejection of claims 1-20 be reconsidered and withdrawn. 

An indication of the allowability of all pending claims by issuance of a Notice of 
Allowability is earnestly solicited. 



Respectfully submitted, 




Paul D. Greeley 
Reg. No. 31,019 
Attorney for Applicants 
Ohlandt, Greeley, Ruggiero & Perle, LLP 
One Landmark Square, 10 th Floor 
Stamford, CT 06901-2682 
Tel: (203) 327-4500 
Fax: (203) 327-6401 
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